Summary

When execution-id logging is enabled, the framework intercepts process.stdout/process.stderr writes and re-decodes the data to attach execution context (src/logger.ts). The Uint8Array branch decoded data.buffer:

decodedData = Buffer.from(data.buffer).toString();

data.buffer is the entire backing ArrayBuffer and ignores the view's byteOffset / byteLength. Node.js allocates most Buffers from a shared internal pool, so a Buffer written to stdout is frequently a view with a non-zero byteOffset into a much larger ArrayBuffer. As a result, decoding data.buffer captures unrelated pool bytes surrounding the real message and produces corrupted log output.

Reproduction

const pool = Buffer.allocUnsafe(64);
const a = pool.subarray(8, 8 + 11);
a.write('hello world');

Buffer.from(a.buffer).toString();
// => 8192-byte string of pool garbage with "hello world" buried in the middle

Buffer.from(a.buffer, a.byteOffset, a.byteLength).toString();
// => "hello world"

In practice this means a user function that does process.stdout.write(Buffer.from('...')) (or logs via any library that emits Buffers) gets garbled logs whenever execution-id support is on.

Fix

Decode only the bytes the view spans:

decodedData = Buffer.from(data.buffer, data.byteOffset, data.byteLength).toString();

Why the existing test didn't catch it

The uint8array test uses new Uint8Array(Buffer.from(sampleText)), which copies into a fresh, exactly-sized ArrayBuffer with byteOffset === 0 and byteLength === buffer.byteLength — the one case where reading data.buffer happens to be correct.

Testing

• Added a regression test that logs through a pooled, non-zero-offset view. It fails before the fix and passes after.
• Full suite green: 107 passing.

🤖 Generated with Claude Code